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Abstract: An innovative method for rapidly calculating spacecraft environmental absorbed heats in planetary 
orbit is described. The method employs reading a database of pre-calculated orbital absorbed heats and 
adjusting those heats for desired orbit parameters. The approach differs from traditional Monte Carlo methods 
that are orbit based with a planet centered coordinate system. The database is based on a spacecraft centered 
coordinated system where the range of all possible sun and planet look angles are evaluated. In an example 
case 37,044 orbit configurations were analyzed for average orbital heats on selected spacecraft surfaces. 
Calculation time was under 2 minutes while a comparable Monte Carlo evaluation would have taken an 
estimated 26 hours. 
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1.0 Introduction 

An innovative method for rapidly calculating spacecraft environmental absorbed heats in 
planetary orbit was developed. The method employs reading a database of pre-calculated 
orbital absorbed heats and adjusting those heats for given orbital conditions. The method 
differs from traditional methods that are orbit based with a planet centered coordinate system. 
In this approach the sun and planet are oriented in the spacecraft coordinate system. The range 
of all possible sun and planet look angles are accounted for in a database. A test database was 
built and a reading/analyzing routine was written. 


The test database was built of separately computed solar, albedo and IR absorbed heats for a 
simplified Crew Exploration Vehicle (CEV) at 1134 uniformly distributed look angles using Monte 
Carlo ray tracing techniques in Thermal Desktop® (TD) [1], The CEV model was constructed 
with 507 nodes. The absorbed heats were computed for a baseline set of planet radius, albedo, 
IR constants and altitude. An orbit generator (ORBGEN) routine was adapted to read the 
database and perform calculations. For an input orbit, ORBGEN will find database points closest 
to the orbit points, perform interpolation between points, modify the absorbed heat values for 
the actual planet parameters and the orbit altitude, and compute data for input queries. 


The spacecraft oriented database Rapid Calculation Method (RCM) can greatly reduce computer 
time compared to calculating orbital heating using planet oriented coordinate methods. In a 
demonstration case (see section 6.0), orbital minimums, maximums, and averages were 
obtained for a group of nodes for 37,044 orbit configurations. RCM took approximately 2 
minutes to calculate. Using TD for each case would have taken about 26 hours. 



2.0 Modeling Assumption 


The database was constructed with these assumptions. 

1 . The planet is a diffuse emitter and reflector. 

2. Only instantaneous direct and reflected environmental heating is calculated. There is no 
emitted radiation between vehicle surfaces due to surface temperature differences. 

3. Planetary solar albedo flux is a function of the vehicle’s sun zenith angle (angle from 
noon), and is constant over the vehicle’s field of view 

4. Variation of planetary albedo and IR absorbed heats with altitude is assumed proportional 
to planet view factor on a surface facing the planet. 

3.0 Construction of Database 

3.1 Uniformly Divided Sphere Used for Attitude Look Angles 

The database, in order to anticipate all possible sun and planet look angles, was built with an isotropic 
sun and planet vector distribution. This uniform vector field was built by using an algorithm that places 
points uniformly on a sphere. The spacecraft is then considered at the center of the sphere (see Fig.l). 
TD has a vector list option for input of solar and planet vectors. 



Figure 1 Sphere with 1134 equally spaced vector directions. The CEV is considered placed at the center of 
the sphere and sun and planet located at vector directions. The angle between adjacent vectors is 
about 6°. 



Program DISC01_JP, listed in Appendix D, was used to generate a set of uniformly distributed look angle 
vectors for the TD vector list input. 


3.2 Writing the Database 

After the model has run for all the vectors (look angles) in the vector list, TD outputs the nodal absorbed 
heats into a text file (SINDA.HRa). The text file has separate listings for solar, albedo, and IR heats for 
each node for each vector. A Fortran program, WriteDatabase5_Andy, listed in Appendix E was written 
to read this text file and construct a binary database. Future enhancements could include reading the 
absorbed heat data directly from TD without the intermediate text file. There is a record for each vector 
in the binary database. The record format is: 

j, PlanetFlag, theta, phis, Qs(j,l:Nnode), Qa(j,l:Nnode), Qp(j,l:Nnode) 


where 


j 

vector number, record number 

PlanetFlag 

planet indicator- not used 

theta 

Inclination (cone) angle 

phis 

azimuthal (clock) angle 

Qs(jl:Nnode) 

nodal solar absorbed heats 

Qa(jl:Nnode) 

nodal albedo absorbed heats 

Qp(jl:Nnode) 

nodal planetary absorbed IR 

Nnode 

Nodes in the model 


At a particular orbit location ORBGEN will search the database for solar and planet look angles that are 
closest to the actual angles. 


The present database was constructed for 1134 vectors with 5000 rays per node and 507 nodes in the 
model. Run time took about 2.7 hrs on a 2.5 GFIz PC computer. The database size is 6.7 MB. The 
current model was not optimized for reduction of runtime or reduction of error. 




4.0 Estimation of Computation Time and Database Size if Correction Methods are not 
Used 

If correction methods are not employed, the number of cases to be computed can be very large. As an 
example database consider: 

Case = position in space with a heat calculation 

A=angles, D=distances(altitudes), N=nodes, Nt=off sub-solar angles, 

If A=10270, D=30, Nt=18 (every 10°, axially symmetric) 

For 2 planets with albedo and IR plus solar heats 

C=4*A*D*Nt + A 

022,000,000 

With 507 nodes in the spacecraft and 5000 rays per node and each ray taking a psec, CPU time would be 
about 650 days. The database size would be 43GB. (On a dual core 2.53 GHz machine it takes about 1 
psec for a ray computation. The runtime could be reduced by running TD in batch mode on several 
machines after hours. This would require COM language programming, see Appendix B.) 

5.0 Using ORBGEN with the Database 

ORBGEN assumes circular orbits, and the vehicle is oriented relative to a planet-oriented coordinate 
system in the current version. Orbit parameters are entered into a text file. If specific node groups are 
of interest they can be entered into another text file, e.g one wishes to find the orbital minimum, 
maximum and average absorbed heats for the radiators. The executable is run and results are output in 
a text file. Appendix F lists DISCOIC, a companion program to DISC01_JP, that generates a look angle 
database for use by ORBGEN. Appendix G lists a sample ORBGEN input case. Appendix H lists the 
corresponding output. Appendix I lists the group absorbed flux summary, Fortran output unit 7. 
Appendices J through N list the Fortran source code for the ORBGEN main routine and its subroutines. 

5.1 Computation of Orbital Absorbed Heats 

In order to limit the number of cases that must be computed in TD, adjustment methods were used to 
compute absorbed heats for orbits with different parameters than the basis set tabulated in Appendix A. 
Orbits with different altitudes and planet radius are scaled according to view factors. Solar, albedo and 
IR constants were also scaled. These methods are discussed below. 

5.2 Correction of Heats Due to Altitude, Albedo and IR Constants 

For surfaces that have a full view of the planet, the view factor to the planet is proportional to 
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Eq. 1 
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where a is the altitude and r the planet radius. Absorbed heats for different radii and altitudes are 
computed by multiplying the database heat value by the ratio of the actual view factor and database 
basis view factor. Absorbed heats for solar, albedo, and IR constants differing from the basis set are 
likewise adjusted and discussed below. 

5.3 Calculation of Lunar and Earth Albedo and Lunar IR 

All planetary heat sources are considered to be diffuse. However only the earth IR can be assumed to 
be uniform, while lunar and earth albedo and lunar IR depend on orbit position, specifically the angular 
distance from the planet sub-solar axis. 

5.3.1 Calculation of Lunar IR 

If one assumes an adiabatic regolith, that all sunshine not reflected is radiated as diffuse IR, then the IR 
radiosity is given by: 


Eq.2 


Where S is the solar constant, p is the solar reflectivity, and is the inclination angle from sub-solar axis 
to the spacecraft orbit position. See Fig. 2. 

5.3.2 Calculation of Planetary Reflected Solar 

Assuming diffuse reflection the planetary reflected solar flux is given by 


Eq. 3 


Where is the solar constant, is reflectivity and is the angle from the sub-solar axis. The current 
absorbed heat calculation algorithm uses the IR or A values from Eq. 2 and Eq. 3 above for scaling. 
There is an error involved in using a constant radiosity value for all the planet surfaces in view of the 
spacecraft, see Fig. 2. TD does not correct for this error, it uses a constant value for all the planet 
surfaces within view of the spacecraft. This error is discussed in Section 8.7. 




Figure 2 A spacecraft view cone over planetary albedo or IR radiosity field. The fields vary with cosine of 
angular distance from the sub-solar axis. Contour lines are equidistant, scale is arbitrary. A 
spacecraft surface will receive energy from areas with possible large variations in radiosity. TD 
does not account for this variation, it uses a constant radiosity value for the planet surface in view 
of the spacecraft. 


6.0 Results 

RCM demonstration cases were run. In one case, with an altitude of 150 miles, the beta angle was 
varied in 15° increments while yaw, pitch and roll were varied in 5° increments. The average absorbed 
heat flux was computed for a group of nodes. Some data samples are shown below, and a partial 
Fortran output data listing is in Appendix H. 


LIDS ELECTRICAL BOXES 








Average Group Absorbed Fluxes - 
W/M**2 








beta 

yaw 

pitch 

roll 

Qs 

Qa 

QP 

Qtotal 

0 

5 

5 

5 

87.97 

30.39 

168.45 

286.82 

0 

15 

0 

0 

83.40 

26.02 

154.42 

263.84 

30 

-15 

-5 

5 

102.15 

19.43 

144.93 

266.51 

60 

10 

15 

0 

83.97 

19.85 

196.24 

300.06 

75 

15 

15 

0 

94.74 

10.17 

196.24 

301.15 


7.0 Description of Routines 

A list of routines that are used to implement RCM are below. 


Routine 

Discription 

Program discojp.f 

Generates a set of uniformly distributed look angle vectors. 
Writes the vector data to ASCII file for use by Thermal Desktop® 

Program discolc.f 

Generates a set of uniformly distributed look angle vectors. 
Writes the vector data to a binary file for use by ORBGEN4. 

Program writedatabase5.f90 

constructs a database by reading SINDA.HRa file 



Program ORBGEN4 

calculates look angles for orbit, reads database, interpolates, 
calculates absorbed heats 

Subroutine 

HMS 

converts decimal hours to hours, minutes and seconds 

Subroutine 

SSTEST 

determines if spacecraft is in sun or shadow 





Subroutine 

SSCALC 

determines look angles 

Subroutine 

ORBPRT 

prints 

Subroutine 

TRANS 

performs Euler rotations 

Subroutine 

FLUX 

modifies database albedo and planetary flux values for planet 
type and altitude 

Subroutine 

INTERP 

interpolates between database look angles and orbit look angles 

Input Files 



input2.nml 

orbit parameters 


inputl.nml 

node list 

Output Files 




fort. 7 

lists nodes groups and average absorbed fluxes at each orbit 
position queried. 


8.0 Future Work 

8.1 COM Language Implementation 

TD allows automation of models runs through an Excel interface using Microsoft COM language (See 
Appendix B). COM scripts were investigated to modify model parameters. COM can be used to build 
the vector list, input planet parameters, set ray numbers etc. Multiple machines could be utilized to run 
TD by scheduling runs after hours. COM scripting will no doubt have to be implemented if the number 
of data points to be computed becomes very large. 

8.2 Oct-Cell Opimization 

Oct-cells are a way TD subdivides the model space to reduce Monte Carlo runtimes. Without oct-cells 
when a ray is cast every surface in the model has to be checked for intersection. By dividing the model 
space into oct-cells, only those surfaces within the cell must be checked. There is an optimum number 
of cells for any model that will produce the shortest runtimes. This has not been thoroughly 
investigated. 

8.3 Flux Cubes 

Flux cube calculations could be added to the database for given points about the spacecraft. Previously 
use of the flux cube technique involved placing a physical cube at the location and tracking orbital 
thermal radiation impinging on the surfaces of the cube [2], The cube acted as a probe in the model but 
it affected the results because it blocked the radiation flux. A proposed enhancement would be to 



incorporate the concept of transparent flux cubes. The rays that encounter a cube face would pass 
through unaffected but the ray would be counted. 

8.4 Investigate Error Size for Each Surface 

The reflected error for a large surface to a small surface can be significant. The error is given by Eq. 4. 



Sy = 1.645 


n i B ij 


Eq. 4 


where n, is the number of rays cast from surface i, By is the energy exchange factor, the fraction of 
energy emitted from surface i that is absorbed on surface j. The error increases for decreasing By. 


Figure 3 The indirect energy from surface i impinging surface j may be a large fraction of all energy 
received at j. The error in this energy calculation may be large. 


Consider surfaces i and j shown in Fig. 3. At some look angles j could receive a significant amount of 
indirect radiation from i. If an insufficient number of rays are cast from i the error in energy exchange 
from i to j could be significant since the amount of radiation leaving i and impinging j is a small fraction 
of all the energy emitted by i. TD allows automatic error criteria to be used in determining the number 
of rays cast from a surface. This method was not used. Future work would involve determining 
acceptable error levels for each surface without unduly increasing runtimes. 



8.5 Corrections for Articulating Surfaces 

The database was constructed with solar and planetary vectors being anti-parallel; the solar arrays 
always tracking the sun as would be expected in an actual orbit. However in an actual orbit the solar 
and earth vectors will be at arbitrary angles and the solar arrays will not have the same orientation as 
calculated in the database. Test cases will have to be run to investigate the size and nature of this error. 
A method for correcting for this error has not been devised. 

8.6 Investigate the Accuracy of View Factor Corrections for Surfaces That Only See 
Partial Planet View 

The view factor for surfaces that see only part of the planet view cone does not have a simple altitude 
adjustment as given in Eq. 1. 



Figure 4 Some spacecraft surfaces with a normal that does not intersect the planet center will only have a 
partial view of the planet. The view cone will be truncated. The relative truncation of the view 
cone will not be the same for a spacecraft surfaces at parallel orientations but different altitudes. 

The nature of the error is due to the fact that although the view cone scales with altitude and radius the 
view angle that subtends the view cone does not remain constant, see Fig. 5. One possible approach 
would be to track surface normals and scale the heats according to view cone truncation along with 
view factor scaling. Another approach is to add altitudes to the database variables and interpolate 
between known altitudes. This approach would increase the size of the database. 


8.7 Estimation of Error Due to Non-Uniform Planet Radiation Fields 

As shown in Fig. 2 spacecraft surfaces receive radiation from a variation of radiation field intensities. 

Fig. 5 shows an example of heat flux computation using a constant radiosity value for all surfaces within 
the view cone and an exact integral calculation that takes into account the variation of radiosity over the 
planet's surface. The Fig. 5 altitude is half of the planet radius, greater than a typical orbit altitude. 
Relative magnitude of the error increases with altitude. 



Figure 5 Heat flux calculated using the value of radiosity at sub spacecraft point and heat flux calculated 

from integration over view cone. Surface normal toward planet center. Exact integration used the 
integration formula discussed in Appendix C. 

8.8 Using Exact Integration to Evaluate Error 

An integral equation was formulated to calculate exact planetary reflected solar. The integral takes into 
account the cosine variation of radiosity fields as well as view cone truncation. The integral can be 
evaluated in MathCad [3], The integral is applicable for flat surfaces with no shadowing but can be 
modified to accommodate curved surfaces. See Appendix C. 


9.0 Conclusions 

A method of rapidly calculating orbital heats on a spacecraft from database values was demonstrated. 
The method can calculate heats for an arbitrary orbit in minutes while a full Monte Carlo simulation may 
take hours. The method was demonstrated on CEV but is applicable to any spacecraft. Additional work 
is required to fully develop the method. 
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